Giga Games 1/Giga Games.iso/net/vir_real/fly/fly.faq

Text File | 1993-06-20 | 13.6 KB | 308 lines

The FLY! Demonstration has generated a lot of questions so here is a
traditional response:  a Frequently Asked Question list.

FLY!-3D Software is available at: ftp.u.washington.edu
(/oldpublic/fly)

1.  What are the differences between the FLY! Demo and the real product?

The FLY! demonstration is a fully functioning copy of the FLY! program
except that it will ONLY work on the supplied demonstration data.


2.  Is there a more extensive demonstration available above and beyond that
    on the Internet?

Yes.  PCI has a demonstration that consists of the following:

a) FLY! exectuables for about 10 different workstations
b) a  512 x  512 data set (tiny.pix)  (1.5 Mbytes)
c) a 1024 x 1024 data set (small.pix) (  6 Mbytes)
d) a 1536 x 1536 data set (big.pix)   ( 15 Mbytes)
e) a hardcopy manual
f) a pair of (cheap) anaglyph (red/blue lensed) glasses for 3-D viewing

Upon special request we can include a 2048 x 2048 (24 Mbytes) data set
and a manual describing the PCIDSK database file format the data sets are
distrbuted in.
* Note:  2048 x 2048 dataset is only useful on machines that have
48+ Mbytes of RAM.

This demonstration is basically identical to that on the InterNet except
that you get some larger data sets and the extra documentation.
To cover the media, shipping and handling costs we ask for $99.  >:-(
You are encouraged to share the demonstration with others or use it on
as many machines as you like (or can get access to).


3.  Who are PCI Inc. anyway?

PCI is a company which develops imaging software for Satellite
and Aircraft Remote Sensing which, we sell all over the world.
We are located in Richmond Hill (Toronto really...), Ontario,
Canada.
FLY! is only one of many products, though probably the most fun...


4.  Why is FLY! special?

The concept of draping image data over elevation is not new, its been
around for 10+ years.  However it has always been slow, on a VAX 780
it would take 15 minutes or more to get a single rendering.
Other approaches in the past solved this problem with special hardware,
obtaining much faster (occasionally realtime) speeds, but at enormous cost.
FLY! combines an innovative algorithm coupled with large amount of RAM
and the fast processing speed of on todays workstations to bring this
time down to the 1/10th to 1 second range.  This means anyone can now have
'near' realtime performance on a general purpose workstation.  No special
purpose hardware add ons or graphics cards are required.

The FLY! algorithm can also be parallelized, more on this in further
question answers.
FLY! considers every pixel as a unique polygon.  This gives maximum
realism in rendering in 3-D.


5.  How fast is the FLY! algorithm?

The speed, in frames per second, depends on a lot of factors:

    - speed of your CPU
    - how big the input database is
    - how big an output rendering frame you want
    - various perspective parameters, such as cone of view...

As a base reference we will consider the following:

    - a 1024 pixel by 1024 line database (1048576 polygon equivalent...)
    - a 320 x 240 output rendered scene
    - a 60 degree view cone

Experimentation across a number of machines has shown that it takes about
22 MIPS of power to generate a rendered scene in 1 (one) second.  For example,

    - a  17 MIPS machine (eg Sparc 1+)   gets about  17/22 =  .8 frames/sec
    - a  33 MIPS machine (eg, SGI 4D-35) gets about  33/22 = 1.5 frames/sec
    - a 130 MIPS machine (eg, DEC Alpha) gets about 130/22 = 6.0 frames/sec

Of course not all MIPS are equal across all machines, and I am not to sure
about the relationship to SPECmarks or SPECints.

We have further noted the following rules:

    - Doubling the database size tends to decrease performance by 25%.
    - Computational power increases with the square of the X size of the
      output rendering frame (Y size is just extra sky and is not important)
      (eg. 640 x 480 output rendered scene requires 22 x 4 = 88 MIPS)

>From these we have developed the following chart which gives the MIPS
required for various configurations to generate a single frame in one second.

Rendering sizes are 160x120, 320x240, 450x170, 640x480.

Database size       1024x1024              2048x2048              4096x4096
Render size    160  320  450  640     160  320  450  640     160  320  450  640
MIPS             6   22   44   88       7   28   56  112       8   34   68  140

Thus given a 2048x2048 database, a 160 by 120 rendering frame, and a DEC alpha
workstation (130 MIPS) we would get 130/7 = 19 frames/second.

Given a 1024x1024 database, a 640 by 480 rendering frame, and a SparcStation 2
(27 MIPS) we would get 27/88 = .31 frames second, or about 3 seconds per frame.

The FLY! algorithm can be run on parallel processors.  We have done this on
the Silicon Graphics Power Series (up to 8 processors).  In general FLY!
scales well.  We have found that the MIPS rating of a parallel machine
(for the purposes of FLY!) can be computed as:

        MIPS = #processors * MIPS/processor * 0.8

The 0.8 is due to the parts of the algorithm which cannot be parallelized
and general overhead.  In the case of an 8 processor SGI we got an effective
MIPS rating of:    8 * 33 * 0.8 = 210 MIPS

Please consider the above figures as rough.  The following factors can change
the above in some way:

    - Whats a MIP anyway?  How do you compare across machines?
    - Large Caches help.
    - You had better have enough RAM.  If ANY disk swapping/thrashing
      occurs the frame rate plummets.  See question on memory below.
    - The quoted MIPS/frame/sec assume a worst case.  If you are near
      an edge looking at the edge frame rates increase...

6.  How much memory is required?

FLY! requires about 8Mbytes of RAM + 6 bytes per database pixel.  Thus a
if FLY! is run with a 1024x1024 database it needs about 8 + 6 = 14Mbytes.
A 2048x2048 database would require about 8 + 24 =  32 Mbyes.
A 4096x4096 database would require about 8 + 96 = 104 Mbytes.

On top of this is the normal OS and X11/Motif requirements, say another 8 to 10
Mbytes.  Thus FLY! using a 1024 x 1024 database should be run on a system with
about 24Mbytes of RAM.

If you don't have enough RAM then the OS will start swapping parts of the FLY!
data to disk.  Since FLY! typically has to look through most of the data for
each frame this creates a LOT of paging and frame rates drop to almost nothing.


7.  Can you tell me more about the FLY! algorithm?

The FLY! algorithm is proprietary, source code is not available.  Like most
interesting things it was developed after hours when we could grab a few
minutes when the pressing work of meetings, documentation, phone tag
and tech support diminished somewhat :-).  No papers have been published.

PCI won't divulge much but we will point out:

    - it uses hierarchies of databases so that as data gets further
      away it uses progressively less computational power.
    - each frame is done 'brute force'.  No information is saved across
      scenes.  This means turning, repositioning has no performance penalty.
    - The inner loops do not use any floating point, everything is
      fixed point.
    - Lots of stuff is table driven.


8.  Why doesn't FLY! make use of the special graphics hardware on my machine?
    Wouldn't this make FLY! even faster? or improve the visual quality?

FLY! was designed to run on the widest variety of hardware possible with the
minimum of programming.  Using special graphics operations would limit the
FLY! to a small subset of machines.  The FLY! algorithm is designed in
such a way that using special graphics shading/polygon rendering would be
very difficult.

Remember that a 1024 x 1024 data base has 1,000,000+ potentially unique
(square) polygons, a 2048x2048 4,000,000+ polygons.  If we divide the squares
to triangle the numbers double.  It is a pretty unique board that can handle
8,000,000 triangles and render the appropriate ones 10 to 20 times per second.

Of course it is possible to reduce the number of polygons/triangles by
approximating large area's and use texture mapping.  This has three drawbacks:

    - the realism and data accuracy is compromised for visual appearance
      (FLY! is primarily a visual analysis tool where accuracy is vital)
    - in 3-D modes (left and right eye) FLY! gives excellent results
      because the input data often has natural shading and lots of
      detail since every pixel is rendered separately.  The brain is uses
      this to give a better 3-D interpretation.
    - Lots of packages already exist that to this type of thing very well.

This is not to say that careful consideration of a particular graphics board,
with substantial changes to the FLY! algorithm, might improve speed/quality,
however PCI has no plans in this direction in the near future.


8.  What about parallelism?

The FLY! algorithm is designed to take advantage of parallel processors.
PCI has tested this on parallel processor Silicon Graphics machines already
and improvements in speed are nearly linear with the number of processors.

FLY! requires the following characteristics for using parallel processors:

    - a Multiple Instruction, Multiple Data (MIMD) architecture
    - every processor must have access to the full shared memory, not just
      a small local amount.
    - there needs to be a large bandwidth to the host computer which
      shows the rendered images.  For example:  for a 512x512 24bit image
      at 10 frames/sec, we need at least 10Mbytes/second to the host
      computer or video board that shows the frames, probably a lot more.
    - Floating point performance is irrelevant, the FLY! algorithm is
      integer.

We have had a number of inquires about using special parallel hardware boards.
Unfortunately, so far, these have not had the characteristics we require.  Also
PCI does not have the resources to reprogram FLY! on the off chance of selling
a limited number of special boards.

More promising is the use of parallel workstations, typically these are
already integrated nicely into the memory/graphics subsystem and simple to
program.  The drawback of course, is limited numbers of processors and a
higher cost, but this is changing slowly.

PCI has already experimented with the SGI Power Series (up to 8 processors).
In the future we hope to try the SGI Onyx series (up to 36), the SUN Sparc
(up to 4) and have heard rumours of parallel HP 700's, DEC Alpha's and
IBM Risc System 6000's (numbers of CPU's unknown).


9.  Is there any other development in progress on FLY!?

Currently development is limited while we evaluate the market potential of FLY!
(and do more boring work on other projects).  However by late summer 1993 you
can expect the following:

    - options to improve rendering quality using fitted polygons and
      interpolated colors in the foreground.  Makes much better looking
      renderings at low altitude, but there is a performance hit.
    - DEC Alpha support (Open VMS and Unix)

In the longer term (say end of 1993) you might see:

    - Flight Planning
    - Windows 3.1, Windows NT, MAC/OS and OS/2 support
    - Parallel versions for other workstations (like SUN)


10. What about Virtual Reality?

PCI, (well us programmers actually, and happily the company President, though
not the sales people who can't see any possible sales for years  ;-)
are really, really interested in doing VR development.

Now, by VR, we mean a head mounted display with at least 10 frames per second
frame rate, at some reasonable resolution (say a minimum of 442 x 350).  FLY!
already has a 3-D option using anaglyph (red/blue) glasses, so we know it can
do a good job of generating left/right images.  We also anticipate interfacing
a cyberglove, for virtual gesture recognition, along with auxilary devices
such as the spaceball, LCD glasses, etc.

The real problem has to do with compute power.  Refering to question 5,
a 2048x2048 database with 450 resolution needs 56 MIPS per frame per second.
Thus 10 frames/sec = 560 MIPS PER eye = 1120 MIPS, minimum.

Now there would be some non parallel overhead and we would probably need to
do some extra work in the foreground to get less blocky images.  Let's say
1400 MIPS all told.  Not many machines out there with this performance,
but still possible.  For example:  an SGI Onyx with 12 processors,
perhaps by the end of '93 an 8 processor Alpha, etc...

While R and D at PCI is gung ho to get such a machine there is the small
problem of cost...  PCI is too small to carry the full burden so we are
currently examining the possibility of sharing costs with a larger
organization.  Some ideas in progress, stay tuned.

Our VR work would concentrate on using true remote sensing (satellite) data
to allow the user to manipulate real world data.  Allowing the user to fly
through 100's of square miles, to manipulate entire mountain ranges, etc...
Applications would be in the area of Geology, Forestry, GIS visualization,
etc...

Of course we have some concern's:  how many frames/second do we need as a
minimum to prevent nausea?;  there is a tendency for the FLY! algorithm to
generate 'shimmer' or speckles in the distance as small objects show up
and disappear with small changes in position/angles, how do we solve this,
or minimize it?;  much of our data is very coarse (e.g., 30 meter resolution)
does this matter, or is there some threshold people require?; what is the
best way to allow the user to interact with the program, a glove?

It might take us a while to start work in this area, but as the cost of
MIPS and VR drop, it is going to happen.

For further technical questions, feel free to contact the
designer of Fly! himself! David Stanley ([e-mail])

We hope you enjoy the demo, and feel free to give us
feedback, positive or negative (flaming excluded :-)
or any ideas, comments, suggestions, etc..


Karim Ismail        | Richmond Hill, Ontario
[e-mail]    | Canada
PCI Inc         | [phone]
Support    Engineer    | [phone] (fax)